enhance: reduce checkpoint GC and index metrics overhead - #27

Summary

Reduce two sources of periodic coordinator allocation without changing their scheduling intervals:

• Add a positive-only, resident collection-availability check for channel-checkpoint GC. A healthy, available collection can be skipped without scheduling DescribeCollection or retaining an entry in the sweep's fallback-result map. Unknown, unavailable, unhealthy, or unsupported cases retain the existing HasCollection and GcConfirm checks; a negative cache result never authorizes deletion.
• Reuse the VChannel parsing regexp and cancel each fallback timeout immediately after its lookup. Parsing semantics remain unchanged.
• Maintain six-state index-task counts at successful in-memory metadata publication points instead of enumerating every build during metrics collection. Recovery uses the existing build walk. Pointer-free, per-index counters retain inactive-index bookkeeping so dropping or reactivating a field index does not require a build scan.

This is a follow-up to #23, targeting codex/load-1m-segments-pr-stack-rebased-qv-work at bc6a0ddbd2adba5da4274bfc2b526abaa70bd8f2.

Related scalability context: milvus-io#48867. That issue concerns million-segment collection recovery; this PR does not claim to resolve its QueryNode recovery problem.

Correctness boundaries

• Preserve the authoritative fallback before deleting checkpoint metadata, including cancellation, collection-pause, not-found, and GcConfirm handling.
• Update counts under the existing metadata lock, after successful persistence. Failed writes, retries, replaced build IDs, and late task completion after field-index deletion must not inflate visible counts.
• Keep existing metric names, labels, all six zero-valued states, and collection intervals. No protocol, schema, configuration, or deployment changes.
• Checkpoint catalog listing remains a full sweep. Quota/SetRates, event-based GC/compaction, and hot/cold metadata separation are out of scope.

Verification

Validated on submission commit d23fdf6147c7a30d2ff2a04b478404df6335b510, after a conflict-free rebase; git range-diff confirmed the patch was unchanged.

All Go tests and benchmarks use -tags dynamic,test -gcflags='all=-N -l':

• Three runs of DataCoord index metadata/count/checkpoint tests and relevant existing GC/index-task regressions.
• Three runs of RootCoord/MixCoord collection-availability and coordinator-broker tests; three full runs of pkg/util/funcutil.
• Race-enabled DataCoord index metadata/count/checkpoint tests and RootCoord collection-availability tests.
• Coverage includes persistence failure and retry, recovery/replacement, deletion/reactivation, late completion, randomized full-scan equivalence, concurrent transitions, and conservative checkpoint fallback.
• Changed-file coordinator lint and full pkg/util/funcutil lint: 0 issues. git diff --check passed.
• Ran required make lint-fix: blocked by pre-existing internal/metastore/kv/querycoord/kv_catalog_test.go:372:15: undefined: mocks. That file is identical in the target base and submission. Ran run_clang_format.sh with clang-format 15. Neither formatter changed any PR file; unrelated formatting output was excluded.

Local performance evidence and limitations

Synthetic benchmarks on Apple M5 / Go 1.26.5, three repetitions with compiler optimizations disabled:

• At 100,000 tasks, the full-scan reference took approximately 14.2 ms and 803 KB per iteration. The count snapshot took approximately 15 ns with 0 B/op; warmed six-gauge publication approximately 1.14 us with 0 B/op. The reference models eligibility and the full build listing, not the exact original implementation; one scan sample had background configuration-refresh allocation noise.
• Shared VChannel regexp: median approximately 1.45 us, 32 B and 1 allocation, versus compile-per-call approximately 3.44 us, 3,139 B and 27 allocations.

Incremental bookkeeping adds O(indexes) resident counter storage and constant work to metadata transitions; it does not make all metadata operations allocation-free. Tests used existing local native artifacts and mocked metadata writes. Full make test-go, a newly built production image, end-to-end deployment tests, and live MixCoord CPU/GC comparison have not been run. No claim is made that this eliminates the deployed CPU sawtooth or achieves a specific live CPU reduction.